perm filename SUPDUP.RFC[NET,MRC] blob
sn#354028 filedate 1978-05-07 generic text, type T, neo UTF8
NWG/RFC# 734 MRC 07-APR-78 01:39 41953
SUPDUP Display Protocol
Network Working Group Mark Crispin
Request for Comments 734 SU-AI
NIC 41953 7 April 1978
SUPDUP Protocol
INTRODUCTION
This document describes the SUPDUP protocol, a highly efficient
display telnet protocol. It originally started as a private protocol
between the ITS systems at MIT to allow a user at any one of these systems
to use one of the others as a display. At the current writing, SUPDUP user
programs exist at many sites, and server programs exist at the four MIT ITS
sites and SU-AI.
The advantage of the SUPDUP protocol over an individual terminal's
protocol is that SUPDUP defines a "virtual" or "software" display terminal
that implements relevant cursor motion operations. The protocol is not
built on any particular display terminal but rather on the set of functions
common to all display terminals; hence it is completely device-
independent. In addition, the protocol also provides for terminals which
cannot handle certain operations, such as line or character insert/delete.
In fact, it is more than this. It provides for terminals which are missing
any set of features, all the way down to model 33 Teletypes.
The advantage over the TELNET protocol is that SUPDUP takes advantage
of the full capabilities of display terminals, although it also has the
ability to run printing terminals.
It is to be noted that SUPDUP operates independently from TELNET; it
is not an option to the TELNET protocol. In addition, certain assumptions
are made about the server and the user programs and their capabilities.
Specifically, it is assumed that the operating system on a server host
provides all the display-oriented features of ITS. However, a server may
elect not to do certain display operations available in SUPDUP; the SUPDUP
protocol is far-reaching enough so that the protocol allows terminals to be
handled as well as that host can handle terminals in general. Of course,
if a host does not support display terminals in any special way, there is
no point in bothering to implement a SUPDUP server since TELNET will work
just as well.
A more complete description of the display facilities of SUPDUP and
ITS can be found by FTP'ing the online file .INFO.;ITS TTY from ARPAnet
host MIT-AI (host 206 octal, 134. decimal). For more information, the
mailing address for SUPDUP is SUPDUP-Group@MIT-AI.
NWG/RFC# 734 MRC 07-APR-78 01:39 41953
SUPDUP Display Protocol
BACKGROUND
The SUPDUP protocol originated as the internal protocol used between
parts of ITS, and between ITS and "intelligent" terminals. Over the
network, a user host acts like an intelligent terminal programmed for ITS.
The way terminal output works in ITS is as follows: The user program
tells the system to do various operations, such as printing characters,
clearing the screen, moving the cursor, etc. These operations are formed
into 8-bit characters (using the %TD codes described below) and stored into
a buffer. At interrupt level, as the terminal demands output, characters
are removed from the buffer and translated into terminal dependent codes.
At this time padding and cursor motion optimization are also done.
In some cases, the interrupt side does not run on the same machine as
the user program. SUPDUP terminals have their "interrupt side" running in
the user host. When SUPDUP is run between two ITS's, the SUPDUP user and
server programs and the network simply move characters from the buffer in
the server machine to the buffer in the user machine. The interrupt side
then runs on the user machine just as if the characters had been generated
locally.
Due to the highly interactive characteristics of both the SUPDUP
protocol and the ITS system, all transactions are strictly character at a
time and all echoing is remote. In addition, all padding and cursor
control optimization must be done by the user.
Because this is also the internals of ITS, the right to change it any
time if necessary to provide new features is reserved by MIT. In
particular, the initial negotiation is probably going to be changed to
transmit additional variables, and additional %TD codes may be added at any
time. User programs should ignore those they don't know about.
The following conventions are used in this document: function keys
(ie, keys which represent a "function" rather than a "graphic character")
are in upper case in square brackets. Prefix keys (ie, keys which generate
no character but rather are held down while typing another character to
modify that character) are in upper case in angle brackets. Hence
"<CONTROL><META>[LINE FEED]" refers to the character generated when both
the CONTROL and META keys are held down while a LINE FEED is typed. Case
should be noted; <CONTROL>A refers to a different character from
<CONTROL>a. Finally, all numbers which do not explicitly specify a base
(ie, octal or decimal) should be read as octal unless the number is
immediately followed by a period, in which case it is decimal.
NWG/RFC# 734 MRC 07-APR-78 01:39 41953
SUPDUP Display Protocol
INITIALIZATION
The SUPDUP server listens on socket 137 octal. ICP proceeds in the
normal way for establishing 8-bit connections. After the ICP is completed,
the user side sends several parameters to the server side in the form of
36.-bit words. Each word is sent through the 8-bit connection as six 6-bit
bytes, most-significant first. Each byte is in the low-order 6 bits of a
character. The first word is the negative of the number of variables to
follow in the high order 18. bits (the low-order 18. bits are ignored),
followed by the values of the TCTYP, TTYOPT, TCMXV, TCMXH, TTYROL, SMARTS,
ISPEED, and OSPEED terminal descriptor variables (these are the names they
are known by at ITS sites). These variables are 36.-bit binary numbers and
define the terminal characteristics for the virtual terminal at the REMOTE
host.
The count is for future compatability. If more variables need to be
sent in the future, the server should assume "reasonable" default values if
the user does not specify them. PDP-10 fans will recognize the format of
the count (ie, -count,,0 in PDP-10 notation) as being an AOBJN pointer. At
the present writing there are eight variables hence this word should be
-10,,0 (or, as a 36.-bit word, 777770000000).
The TCTYP variable defines the terminal type. It MUST be 7 (%TNSFW).
Any other value is a violation of protocol. This isn't strictly true; but
a non-%TNSFW value is outside the protocol and is not guaranteed to work.
The TTYOPT variable specifies what capabilities or options the user's
terminal has. A bit being true implies that the terminal has this option.
This variable also includes user options which the user may wish to alter
at his or her own descretion; these options are included since they may be
specified along with the terminal capabilities in the initial negotiation.
See below for the relevant TTYOPT bits.
The TCMXV variable specifies the screen height in number of lines.
The TCMXH variable specifies the line width in number of characters.
This value is one less than the screen width (ITS indicates line overflow
by outputting an exclamation point at the end of the display line before
moving to the next line). Note: the terminal must not do an automatic
CRLF when a character is printed in the rightmost column. If this is
unavoidable, the user SUPDUP must decrement the width it sends by one.
Note: Setting either the TCMXV or TCMXH dimension greater than 128.
is not guaranteed to work, since coordinates are sometimes represented in
only 7 bits. The main problems occur in the SUPDUP protocol when sending
the cursor position after an output reset and in ITS user programs using
the display position codes ↑PH and ↑PV.
The TTYROL variable specifies the "glitch count" when scrolling. This
is the number of lines to scroll up when scrolling is required. If zero,
the terminal is not capable of scrolling. 1 is the usual value, but some
terminals glitch up by more than one line when they scroll.
The SMARTS variable specifies what "smarts" (in general, what graphics
capabilities) the terminal has. Like the TTYOPT variable, a bit being true
implies that the terminal has this option. See below under the SUPDUP
graphics extension.
NWG/RFC# 734 MRC 07-APR-78 01:39 41953
SUPDUP Display Protocol
INITIALIZATION (continued)
The ISPEED and OSPEED variables are respectively the input and output
baud rates of the terminal, if known. For example, a 150./1200. baud
terminal would have an ISPEED of 150. and an OSPEED of 1200. A speed of
zero means the speed is indeterminate.
Following the transmission of the terminal options by the user, the
server should respond with an ASCII greeting message, terminated with a
%TDNOP code (%TD codes are described below). All transmissions from the
server after the %TDNOP are either printing characters or virtual terminal
display codes.
The user and the server now both communicate using the intelligent
terminal protocol (described below) from the user and %TD codes from the
server. The user has two commands in addition to these; they are escaped
by sending 300 (octal). If following the escape is a 301 (octal), the
server should attempt to log off the remote job (generally this is sent
immediately before the user disconnects, so this logout procedure should be
done regardless of the continuing integrity of the connection). If the
character following the escape is a 302 (octal), all ASCII characters
following up to a null (000 octal) are interpreted as "console location"
which the server can handle as it pleases. No carriage return or line feed
should be in the console location text. Normally this is saved away to be
displayed by the "who" command when other users ask where this user is
located.
NWG/RFC# 734 MRC 07-APR-78 01:39 41953
SUPDUP Display Protocol
TTYOPT FUNCTION BITS
The relevant TTYOPT bits for SUPDUP usage follow. The values are
given in octal, with the left and right 18-bit halves separated by ",," as
in the usual PDP-10 convention.
Bit name Value Meaning
%TOALT 200000,,0 characters 175 and 176 are converted to
altmode (033) on input.
%TOERS 40000,,0 this terminal is capable of selectively
erasing its screen. That is, it supports
the %TDEOL, the %TDDLF, and (optionally)
the %TDEOF operations. For terminals
which can only do single-character
erasing, see %TOOVR.
%TOMVB 10000,,0 this terminal is capable of backspacing
(ie, moving the cursor backwards).
%TOSAI 4000,,0 this terminal has the Stanford/ITS
extended ASCII graphics character set.
%TOOVR 1000,,0 this terminal is capable of overprinting;
if two characters are displayed in the
same position, they will both be visible,
rather than one replacing the other.
Lack of this capability but the capability
to backspace (see %TOMVB) implies that the
terminal can do single character erasing
by overstriking with a space. This allows
terminals without the %TOERS capability to
have display-style "rubout processing", as
this capability depends upon either %TOERS
or [%TOMVB and not %TOOVR].
%TOMVU 400,,0 this terminal is capable of moving the
cursor upwards.
%TOLWR 20,,0 this terminal's keyboard is capable of
generating lowercase characters; this bit
is mostly provided for programs which want
to know this information.
%TOFCI 10,,0 this terminal's keyboard is capable of
generating CONTROL and META characters as
described below.
%TOLID 2,,0 this terminal is capable of doing line
insert/delete operations, ie, it supports
%TDILP and %TDDLP.
%TOCID 1,,0 this terminal is capable of doing
character insert/delete operations, ie, it
supports %TDICP and %TDDCP.
NWG/RFC# 734 MRC 07-APR-78 01:39 41953
SUPDUP Display Protocol
TTYOPT FUNCTION BITS (continued)
Bit name Value Meaning
%TPCBS 0,,40 this terminal is using the "intelligent
terminal protocol".
THIS BIT MUST BE ON.
%TPORS 0,,10 the server should process output resets
instead of ignoring them.
IT IS HIGHLY RECOMMENDED THAT THIS BIT BE
ON; OTHERWISE THERE MAY BE LARGE DELAYS IN
ABORTING OUTPUT.
The following bits are user option bits. They may be set or not set
at the user's discretion. The bits that are labelled "normally on" are
those that are normally set on when a terminal is initialized (ie, by
typing [CALL] on a local terminal).
Bit name Value Meaning
%TOCLC 100000,,0 convert lower-case input to upper case.
Many terminals have a "shift lock" key
which makes this option useless.
NORMALLY OFF.
%TOSA1 2000,,0 characters 001-037 should be displayed
using the Stanford/ITS extended ASCII
graphics character set instead of uparrow
followed by 100+character.
NORMALLY OFF.
%TOMOR 200,,0 the system should provide "**MORE**"
processing when the cursor reaches the
bottom line of the screen. **MORE**
processing is described in ITS TTY.
NORMALLY ON.
%TOROL 100,,0 the terminal should scroll when attempting
output below the bottom line of the screen
instead of wrapping around to the top.
NORMALLY OFF.
%TPPRN 0,,200 the system should swap parenthesis with
square brackets on input. This is often
desirable for LISP users who are using a
terminal which has parenthesis as a shift
character but not square brackets.
NORMALLY OFF.
NWG/RFC# 734 MRC 07-APR-78 01:39 41953
SUPDUP Display Protocol
INPUT -- THE INTELLIGENT TERMINAL PROTOCOL
Note: only the parts of the intelligent terminal protocol relevant to
SUPDUP are discussed here. For more information, read ITS TTY.
CHARACTER SETS
There are two character sets available for use with SUPDUP; the 7-bit
character set of standard ASCII, and the 12-bit character set of extended
ASCII. Extended ASCII has 5 high order or "bucky" bits on input and has
graphics for octal 000-037 and 177 (see the section entitled "Stanford/ITS
character set" for more details). The two character sets are identical on
output since the protocol specifies that the host should never send the
standard ASCII formatting characters (ie, TAB, LF, VT, FF, CR) as
formatting characters; the characters whose octal values are the same as
these formatting characters are never output unless the user job has these
characters enabled (setting %TOSAI and %TOSA1 generally does this).
Input differs dramatically between the 7-bit and 12-bit character
sets. In the 7-bit character set, all characters input whose value is 037
octal or less are assumed to be (ASCII) control characters. In the 12-bit
character set, there are 5 "bucky" bits which may be attached to the
character. The two most important of these are CONTROL and META, which
form a 9-bit character set. TOP is used to distinguish between printing
graphics in the extended character set and ASCII controls. The other two
are reserved and should be ignored. Since both 7-bit and 12-bit terminals
are commonly in use, 0001, 0301, and 0341 are considered to be <CONTROL>A
on input by most programs, while 4001 is considered to be downwards arrow.
MAPPING BETWEEN CHARACTER SETS
Many programs and hosts do not process 12-bit input. In this case,
12-bit input is folded down to 7-bit as follows: TOP and META are
discarded. If CONTROL is on, then if the 7-bit part of the character
specifies a lower case alphabetic it is converted to upper case; then if
the 7-bit part is between 077 and 137 the 100 bit is complemented or if the
7-bit part is 040 the 040 bit is subtracted (that's right, <CONTROL>? is
converted to [RUBOUT] and <CONTROL>[SPACE] is converted to [NULL]). In any
case the CONTROL bit is discarded, and the remainder is treated as a 7-bit
ASCII character. It should be noted that in this case downwards arrow is
read by the program as standard ASCII <CONTROL>A.
Servers which expect 12-bit input and are told to use the 7-bit
character set should do appropriate unfolding from the 7-bit character set
to 12-bit. It is up to the individual server to decide upon the unfolding
scheme. On ITS, user programs that use the 12-bit character set generally
have an alternative method for 7-bit; this often takes the form of prefix
characters indicating that the next character should be "controllified" or
"metized", etc.
NWG/RFC# 734 MRC 07-APR-78 01:39 41953
SUPDUP Display Protocol
INPUT -- THE INTELLIGENT TERMINAL PROTOCOL (continued)
BUCKY BITS
Under normal circumstances, characters input from the keyboard are
sent to the foreign host as is. There are two exceptions; the first occurs
when an octal 034 character is to be sent; it must be quoted by being sent
twice, because 034 is used as an escape character for protocol commands.
The second exception occurs when %TOFCI is set and a character with
non-zero bucky bits is to be sent. In this case, the character, which is
in the 12-bit form:
Name Value Description
%TXTOP 4000 This character has the <TOP> key depressed.
%TXSFL 2000 Reserved, must be zero.
%TXSFT 1000 Reserved, must be zero.
%TXMTA 400 This character has the <META> key depressed.
%TXCTL 200 This character has the <CONTROL> key depressed.
%TXASC 177 The ASCII portion of the character
is sent as three bytes. The first byte is always 034 octal (that is why
034 must be quoted). The next byte contains the "bucky bits", ie, the
%TXTOP through %TXCTL bits, shifted over 7 bits (ie, %TXTOP becomes 20)
with the 100 bit on. The third byte contains the %TXASC part of the
character. Hence the character <CONTROL><META>[LINE FEED] is sent as 034
103 012.
OUTPUT RESETS
The intelligent terminal protocol also is involved when a network
interrupt (INR/INS) is received by the user program. The user program
should increment a count of received network interrupts when this happens.
It should not do any output, and if possible abort any output in progress,
if this count is greater than zero (NOTE: the program MUST allow for the
count to go less than zero).
Since the server no longer knows where the cursor is, it suspends all
output until the user informs it of the cursor position. This also gives
the server an idea of how much was thrown out in case it has to have some
of the aborted output displayed at a later time. The user program does
this when it receives a %TDORS from the server. When this happens it
should decrement the "number of received network interrupts" count
described in the previous paragraph and then send 034 followed by 020, the
vertical position, and the horizontal position of where the cursor
currently is located on the user's screen.
NWG/RFC# 734 MRC 07-APR-78 01:39 41953
SUPDUP Display Protocol
OUTPUT -- DISPLAY PROTOCOL (%TD CODES)
Display output is somewhat simpler. Codes less than 200 octal are
printing characters and are displayed on the terminal (see the section
describing the "Stanford/ITS character set"). Codes greater than or equal
to 200 (octal) are known as "%TD codes", so called since their names begin
with %TD. The %TD codes that are relevant to SUPDUP operation are listed
here. Any other code received should be ignored, although a bug report
might be sent to the server's maintainers. Note that the normal ASCII
formatting characters (011 - 015) do NOT have their formatting sense under
SUPDUP and should not occur at all unless the Stanford/ITS extended ASCII
character set is in use (ie, %TOSAI is set in the TTYOPT word).
For cursor positioning operations, the top left corner is (0,0), ie,
vertical position 0, horizontal position 0.
%TD code Value Meaning
%TDMOV 200 General cursor position code. Followed by
four bytes; the first two are the "old"
vertical and horizontal positions and may
be ignored. The next two are the new
vertical and horizontal positions. The
cursor should be moved to this position.
On printing consoles (non %TOMVU), the old
vertical position may differ from the true
vertical position; this can occur when
scrolling. In this case, the user program
should set its idea of the old vertical
position to what the %TDMOV says and then
proceed. Hence a %TDMOV with an old vpos
of 20. and a new vpos of 22. should always
move the "cursor" down two lines. This is
used to prevent the vertical position from
becoming infinite.
%TDMV1 201 An internal cursor motion code which
should not be seen; but if it is, it has
two argument bytes after it and should be
treated the same as %TDMV0.
%TDEOF 202 Erase to end of screen. This is an
optional function since many terminals do
not support this. If the terminal does
not support this function, it should be
treated the same as %TDEOL.
%TDEOF does an erase to end of line, then
erases all lines lower on the screen than
the cursor. The cursor does not move.
%TDEOL 203 Erase to end of line. This erases the
character position the cursor is at and
all positions to the right on the same
line. The cursor does not move.
NWG/RFC# 734 MRC 07-APR-78 01:39 41953
SUPDUP Display Protocol
OUTPUT -- DISPLAY PROTOCOL (%TD CODES) (continued)
%TD code Value Meaning
%TDDLF 204 Clear the character position the cursor is
on. The cursor does not move.
%TDCRL 207 If the cursor is not on the bottom line of
the screen, move cursor to the beginning
of the next line and clear that line. If
the cursor is at the bottom line, scroll
up.
%TDNOP 210 No-op; should be ignored.
%TDORS 214 Output reset. This code serves as a data
mark for aborting output much as IAC DM
does in the ordinary TELNET protocol.
%TDQOT 215 Quotes the following character. This is
used when sending 8-bit codes which are
not %TD codes, for instance when loading
programs into an intelligent terminal.
The following character should be passed
through intact to the terminal.
%TDFS 216 Non-destructive forward space. The cursor
moves right one position; this code will
not be sent at the end of a line.
%TDMV0 217 General cursor position code. Followed by
two bytes; the new vertical and horizontal
positions.
%TDCLR 220 Erase the screen. Home the cursor to the
top left hand corner of the screen.
%TDBEL 221 Generate an audio tone, bell, whatever.
%TDILP 223 Insert blank lines at the cursor; followed
by a byte containing a count of the number
of blank lines to insert. The cursor is
unmoved. The line the cursor is on and
all lines below it move down; lines moved
off the bottom of the screen are lost.
%TDDLP 224 Delete lines at the cursor; followed by a
count. The cursor is unmoved. The first
line deleted is the one the cursor is on.
Lines below those deleted move up. Newly-
created lines at the bottom of the screen
are blank.
NWG/RFC# 734 MRC 07-APR-78 01:39 41953
SUPDUP Display Protocol
OUTPUT -- DISPLAY PROTOCOL (%TD CODES) (continued)
%TD code Value Meaning
%TDICP 225 Insert blank character positions at the
cursor; followed by a count. The cursor
is unmoved. The character the cursor is
on and all characters to the right on the
current line move to the right; characters
moved off the end of the line are lost.
%TDDCP 226 Delete characters at the cursor; followed
by a count. The cursor is unmoved. The
first character deleted is the one the
cursor is on. Newly-created characters at
the end of the line are blank.
%TDBOW 227 Display black characters on white screen.
HIGHLY OPTIONAL.
%TDRST 230 Reset %TDBOW and such any future options.
%TDGRF 231 Enter graphics mode. Any %TD code may be
used to leave; %TDNOP is preferred. See
below under the SUPDUP graphics extension.
NWG/RFC# 734 MRC 07-APR-78 01:39 41953
SUPDUP Display Protocol
STANFORD/ITS CHARACTER SET
This section describes the extended ASCII character set. It
originated with the SAIL's character set but was modified for 1968 ASCII.
This character set only applies to terminals with the %TOSAI and
%TOFCI bits set in its TTYOPT word. For non-%TOSAI terminals, the standard
ASCII printing characters are the only available output characters. For
non-%TOFCI terminals, the standard ASCII characters are the only available
input characters.
PRINTING CHARACTERS
The first table describes the printing characters. For output, the
7-bit code is sent (terminal operations are performed by %TD codes). For
input, the characters with values 000-037 and 177 must have the %TXTOP bit
on to indicate a graphic is intended rather than a function or ASCII CTRL.
Value Character
4000 centered dot
4001 downward arrow
4002 alpha
4003 beta
4004 logical AND
4005 logical NOT
4006 epsilon
4007 pi
4010 lambda
4011 gamma
4012 delta
4013 uparrow
4014 plus-minus
4015 circle-plus
4016 infinity
4017 partial delta
4020 proper subset (left horseshoe)
4021 proper superset (right horseshoe)
4022 intersection (up horseshoe)
4023 union (downward horseshoe)
4024 universal quantifer
4025 existential quantifier
4026 circle-X
4027 double arrow
4030 left arrow
4031 right arrow
4032 not-equal
4033 lozenge (diamond)
4034 less-than-or-equal
4035 greater-than-or-equal
4036 equivalence
4037 logical OR
0040 first standard ASCII character (space)
.. . . .
0176 last standard ASCII character (tilde)
4177 integral
NWG/RFC# 734 MRC 07-APR-78 01:39 41953
SUPDUP Display Protocol
STANFORD/ITS CHARACTER SET (continued)
FUNCTION KEYS AND SPECIAL CHARACTERS
In addition, the following special characters exist for input only.
These characters are function keys rather than printing characters;
however, some of these characters have some format effect or graphic which
they echo as; the host, not the SUPDUP program, handles any such mappings.
Value Character Usual echo Usual Function
0000 [NULL]
0010 [BACK SPACE] text formatting
0011 [TAB] text formatting
0012 [LINE FEED] text formatting
0013 [VT] text formatting
0014 [FORM] text formatting
0015 [RETURN] text formatting
0032 [CALL] uparrow-Z escape to system
0033 [ALTMODE] lozenge or $ special activation
0037 [BACK NEXT] uparrow-underscore monitor command prefix
0177 [RUBOUT] character delete
4101 [ESCAPE] local terminal command
4102 [BREAK] local subsystem escape
4103 [CLEAR]
4110 [HELP] requests a help message
BUCKY BITS
For all input characters, the following "bucky bits" may be added to
the character. Their interpretation depends entirely upon the host. <TOP>
is not listed here, as it has been considered part of the character in the
previous tables.
<CONTROL> is different from ASCII CTRL, however, many programs may
request the operating system to map such characters to the ASCII forms
(with the <TOP> bit off). In this case <META> is ignored.
Value Key
2000 Reserved
1000 Reserved
0400 <META>
0200 <CONTROL>
NWG/RFC# 746 RMS 23-MAR-78 01:27 43976
SUPDUP Graphics Extension
Network Working Group Richard Stallman
Request for Comments 746 MIT-AI
NIC 43976 8 May 1978
The SUPDUP Graphics Extension
... extends SUPDUP to permit the display of drawings on the screen of
the terminal, as well as text. We refer constantly to the documentation of
the SUPDUP protocol, described by Crispin in RFC 734 "SUPDUP Protocol".
Since this extension has never been implemented, it presumably has
some problems. It is being published to ask for suggestions, and to
encourage someone to try to bring it up.
The major accomplishments are these:
* It is easy to do simple things.
* Any program on the server host can at any time begin outputting
pictures. No special preparations are needed.
* No additional network connections are needed. Graphics commands
go through the normal text output connection.
* It has nothing really to do with the network. It is suitable
for use with locally connected intelligent display terminals in a
terminal-independent manner, by programs which need not know
whether they are being used locally or remotely. It can be used
as the universal means of expression of graphics output, for
whatever destination. Programs can be written to use it for
non-network terminals, with little loss of convenience, and
automatically be usable over the ARPA network.
* Loss of output (due, perhaps, to a "silence" command typed by the
user) does not leave the user host confused.
* The terminal does not need to be able to remember the internal
"semantic" structure of the picture being displayed, but just the
lines and points, or even just bits in a bit matrix.
* The server host need not be able to invoke arbitrary
terminal-dependent software to convert a standard language into
one that a terminal can use. Instead, a standard language is
defined which all programmable terminals can interpret easily.
Major differences between terminals are catered to by
conventions for including enough redundant information in the
output stream that all types of terminals will have the necessary
information available when it is needed, even if they are not
able to remember it in usable form from one command to another.
Those interested in network graphics should read about the Multics
Graphics System, whose fundamental purpose is the same, but whose
particular assumptions are very different (although it did inspire a few of
the features of this proposal).
NWG/RFC# 746 RMS 08-MAY-78 20:45 43976
SUPDUP Graphics Extension
SUPDUP Initial Negotiation:
One new optional variable, the SMARTS variable, is defined. It should
follow the other variables sent by the SUPDUP user process to the SUPDUP
server process. Bits and fields in the left half-word of this variable are
given names starting with "%TQ". Bits and fields in the right half are
given names starting with "%TR". Not all of the SMARTS variable has to do
with the graphics protocol, but most of it does. The %TQGRF bit should be
1 if the terminal supports graphics output at all.
Invoking the Graphics Protocol:
Graphics mode is entered by a %TDGRF (octal 231) code in the output
stream. Following characters in the range 0 - 177 are interpreted
according to the graphics protocol. Any character 200 or larger (a %TD
code) leaves graphics mode, and then has its normal interpretation. Thus,
if the server forgets that the terminal in graphics mode, the terminal will
not long remain confused.
Once in graphics mode, the output stream should contain a sequence of
graphics protocol commands, each followed by its arguments. A zero as a
command is a no-op. To leave graphics mode deliberately, it is best to use
a %TDNOP.
NWG/RFC# 746 RMS 08-MAY-78 20:45 43976
SUPDUP Graphics Extension
Co-ordinates:
Graphics mode uses a cursor position which is remembered from one
graphics command to the next while in graphics mode. The graphics mode
cursor is not the same one used by normal type-out: Graphics protocol
commands have no effect on the normal type-out cursor, and normal type-out
has no effect on the graphics mode cursor. In addition, the graphics
cursor's position is measured in dots rather than in characters. The
relationship between the two units (dots, and characters) is recorded by
the %TQHGT and %TQWID fields of the SMARTS variable of the terminal, which
contain the height and width in dots of the box occupied by a character.
The size of the screen in either dimension is assumed to be the length of a
character box times the number of characters in that direction on the
screen. If the screen is actually bigger than that, the excess may or may
not be part of the visible area; the program will not know that it exists,
in any case.
Each co-ordinate of the cursor position is a 14-bit signed number,
where zero is at the center of the screen (if the screen dimension is an
even number of dots, then the visible negative points extend one unit
farther than the positive ones, in proper two's complement fashion).
Excessively large values of the co-ordinates will be off the screen, but
are still meaningful.
An alternate mode is defined, which some terminals may support, in
which virtual co-ordinates are used. The specified co-ordinates are still
14-bit signed numbers, but instead of being in units of physical dots on
the terminal, it is assumed that +4000 octal is the top of the screen or
the right edge, while -4000 octal is the bottom of the screen or the left
edge. The terminal is responsible for scaling these virtual co-ordinates
into units of screen dots. Not all terminals need have this capability;
the %TQVIR bit in the SMARTS variable indicates that it exists. To use
virtual co-ordinates, the server should send a %GOVIR; to use physical
co-ordinates again, it should send a %GOPHY. These should be repeated at
intervals, such as when graphics mode is entered, even though the terminal
must attempt to remember the state of the switch anyway. This repetition
is so that a loss of some output will not cause unbounded confusion.
The virtual co-ordinates are based on a square. If the visible area
on the terminal is not a square, then the standard virtual range should
correspond to a square around the center of the screen, and the rest of the
visible area should correspond to virtual co-ordinates just beyond the
normally visible range.
Graphics protocol commands take two types of cursor position
arguments, absolute ones and relative ones. Commands that take address
arguments generally have two forms, one for each type of address. A
relative address consists of two offsets, delta-X and delta-Y, from the old
cursor position. Each offset is a 7-bit two's complement number occupying
one character. An absolute address consists of two co-ordinates, each 14
bits long, occupying two characters, each of which conveys 7 bits. The X
co-ordinate or offset precedes the Y. Both types of address set the
running cursor position which will be used by the next address, if it is
relative. It is perfectly legitimate for parts of objects to go off the
screen. What happens to them is not terribly important, as long as it is
not disastrous, does not interfere with the
NWG/RFC# 746 RMS 08-MAY-78 20:45 43976
SUPDUP Graphics Extension
reckoning of the cursor position, and does not cause later objects, drawn
after the cursor moves back onto the screen, to be misdrawn.
Whether a particular spot on the screen is specified with an absolute
or a relative address is of no consequence. The sequence in which they are
drawn is of no consequence. Each object is independent of all others, and
exists at the place which was specified, in one way or other, by the
command that created it. Relative addresses are provided for the sake of
data compression. They are not an attempt to spare programs the need for
the meagre intelligence required to convert between absolute and relative
addresses; more intelligence than that will surely be required for other
aspects of the graphics protocol. Nor are relative addresses intended to
cause several objects to relocate together if one is "moved" or erased.
Terminals are not expected to remember any relation between objects once
they are drawn. Most will not be able to.
Although the cursor position on entry to graphics mode remains set
from the last exit, it is wise to reinitialize it with a %GOMVA command
before any long transfer, to limit the effects of lost output.
NWG/RFC# 746 RMS 08-MAY-78 20:45 43976
SUPDUP Graphics Extension
Commands:
Commands to draw an object always have counterparts which erase the
same object. On a bit matrix terminal, erasure and drawing are almost
identical operations. On a display list terminal, erasure involves
searching the display list for an object with the specified characteristics
and deleting it from the list. Thus, on such terminals you can erase an
object only if precisely that object was drawn, and was specified the same
way when drawn as when erased (presumably; a very hairy program might allow
more). Any terminal whose %TOERS bit is set must be able to erase at least
that extent.
The commands to draw objects run from 100 to 137, while those to erase
run in a parallel sequence from 140 to 177. Other sorts of operations have
command codes below 100. Meanwhile, the 20 bit in the command code says
which type of addresses are used as arguments: if the 20 bit is set,
absolute addresses are used. Graphics commands are given names starting
with "%GO".
Graphics often uses characters. The %GODCH command is followed by a
string of characters to be output, terminated by a zero. The characters
must be single-position printing characters. On most terminals, this
limits them to ASCII graphic characters. Terminals with %TOSAI set in the
TTYOPT variable allow all characters 0-177. The characters are output at
the current graphics cursor position (the lower left hand corner of the
first character's rectangle being placed there), which is moved as the
characters are drawn. The normal type-out cursor is not relevant and its
position is not changed. The cursor position at which the characters are
drawn may be in between the lines and columns used for normal type-out.
The %GOECH command is similar to %GODCH but erases the characters specified
in it. To clear out a row of character positions on a bit matrix terminal
without having to respecify the text, a rectangle command may be used.
Example:
The way to send a simple line drawing is this:
%TDRST ;Reset all graphics modes.
%TDGRF ;Enter graphics.
%GOCLR ;Clear the screen.
%GOMVA xx yy ;Set cursor.
%GODLA xx yy ;Draw line from there.
<< repeat last two commands for each line >>
%TDNOP ;Exit graphics.
NWG/RFC# 746 RMS 08-MAY-78 20:45 43976
SUPDUP Graphics Extension
Graphics Input:
The %TRGIN bit in the right half of the SMARTS variable indicates that
the terminal can supply a graphic input in the form of a cursor position on
request. Sending a %GOGIN command to the terminal asks to read the cursor
position. It should be followed by an argument character that will be
included in the reply, and serve to associate the reply with the particular
request for input that elicited it. The reply should have the form of a
Top-Y character (code 4131), followed by the reply code character as just
described, followed by an absolute cursor position. Since Top-Y is not
normally meaningful as input, %GOGIN replies can be distinguished reliably
from keyboard input. Unsolicited graphic input should be sent using a
Top-X instead of a Top-Y, so that the program can distinguish them.
Instead of a reply code, for which there is no need, the terminal should
send an encoding of the buttons pressed by the user on his input device, if
it has more than one.
Sets:
Terminals may define the concept of a "set" of objects. There are up
to 200 different sets, each of which can contain arbitrarily many objects.
At any time, one set is selected; objects drawn become part of that set,
and objects erased are removed from it. Objects in a set other than the
selected one cannot be erased without switching to the sets that contain
them. A set can be made temporarily invisible, as a whole, without being
erased or its contents forgotten; and it can then be made instantly visible
again. Also, a whole set can be moved. A set has at all times a point
identified as its "center", and all objects in it are actually remembered
relative to that center, which can be moved arbitrarily, thus moving all
the objects in the set at once. Before beginning to use a set, therefore,
one should "move" its center to some absolute location. Set center motion
can easily cause objects in the set to move off screen. When this happens,
it does not matter what happens temporarily to those objects, but their
"positions" must not be forgotten, so that undoing the set center motion
will restore them to visibility in their previous positions. Sets are not
easily implemented on bit matrix terminals, which should therefore ignore
all set operations (except, for a degenerate interpretation in connection
with blinking, if that is implemented). The %TQSET bit in the SMARTS
variable of the terminal indicates that the terminal implements multiple
sets of objects.
On a terminal which supports multiple sets, the %GOCLR command should
empty all sets and mark all sets "visible" (perform a %GOVIS on each one).
So should a %TDCLR SUPDUP command. Thus, any program which starts by
clearing the screen will not have to worry about initializing the states of
all sets.
NWG/RFC# 746 RMS 08-MAY-78 20:45 43976
SUPDUP Graphics Extension
Blinking:
Some terminals have the ability to blink objects on the screen. The
command %GOBNK meaning make the current set blink. All objects in it
already begin blinking, and any new objects also blink. %GOVIS or %TOINV
cancels the effect of a %GOBNK, making the objects of the set permanently
visible or invisible. %TQBNK indicates that the terminal supports blinking
on the screen.
However, there is a problem: some intelligent bit matrix terminals
may be able to implement blinking a few objects, if they are told in
advance, before the objects are drawn. They will be unable to support
arbitrary use of %GOBNK, however.
The solution to the problem is a convention for the use of %TOBNK
which, together with degenerate definitions for set operations, makes it
possible to give commands which reliably work on any terminal which
supports blinking.
On a terminal which sets %TQBNK but not %TQSET, %GOBNK is defined to
cause objects which are drawn after it to be drawn blinking. %GOSET
cancels this, so following objects will be drawn unblinking. This is
regardless of the argument to the %GOSET.
Thus, the way for a program to work on all terminals with %TQBNK,
whether they know about sets or not, is: to write a bliniking picture,
select some set other than your normal one (set 1 will do), do %GOBNK,
output the picture, and reselect set 0. The picture will blink, while you
draw things in set 0. To draw more blinking objects, you must reselect set
1 and do another %GOBNK. Simply reselecting set 1 will not work on
terminals which don't really support sets, since they don't remember that
the blinking objects are "in set 1" and not "in set 0".
Erasing a blinking object should make it disappear, on any terminal
which implements blinking. On bit matrix terminals, blinking MUST always
be done by XORing, so that the non-blinking background is not destroyed.
%GOCLS, on a terminal which supports blinking but not sets, should
delete all blinking objects. Then, the convention for deleting all
blinking objects is to select set 1, do a %GOCLS, and reselect set 0. This
has the desired effect on all terminals. This definition of %GOCLS causes
no trouble on non-set terminals, since %GOCLS would otherwise be
meaningless to them.
To make blinking objects stop blinking but remain visible is possible
with a %GOVIS on a terminal which supports sets. But in general the only
way to do it is to delete them and redraw them as permanent.
NWG/RFC# 746 RMS 08-MAY-78 20:45 43976
SUPDUP Graphics Extension
Rectangles and XOR Mode:
Bit matrix terminals have their own operations that display list
terminals cannot duplicate. First of all, they have XOR mode, in which
objects drawn cancel existing objects when they overlap. In this mode,
drawing an object and erasing it are identical operations. All %GOD..
commands act IDENTICALLY to the corresponding %GOE..'s. XOR mode is
entered with a %GOXOR and left with a %GOIOR. Display list terminals will
ignore both commands. For that reason, the program should continue to
distinguish draw commands from erase commands even in XOR mode. %TQXOR
indicates a terminal which implements XOR mode. XOR mode, when set,
remains set even if graphics mode is left and re-entered. However, it is
wise to re-specify it from time to time, in case output is lost.
Bit matrix terminals can also draw solid rectangles. They can thus
implement the commands %GODRR, %GODRA, %GOERR, and %GOERA. A rectangle is
specified by taking the current cursor position to be one corner, and
providing the address of the opposite corner. That can be done with either
a relative address or an absolute one. The %TQREC bit indicates that the
terminal implements rectangle commands.
Of course, a sufficiently intelligent bit matrix terminal can provide
all the features of a display list terminal by remembering display lists
which are redundant with the bit matrix, and using them to update the
matrix when a %GOMSR or %GOVIS is done. However, most bit matrix terminals
are not expected to go to such lengths.
NWG/RFC# 746 RMS 08-MAY-78 20:45 43976
SUPDUP Graphics Extension
How Several Processes Can Draw On One Terminal Without Interfering With
Each Other:
If we define "input-stream state" information to be whatever
information which can affect the action of any command, other than what is
contained in the command, then each of the several processes must have its
own set of input-stream state variables.
This is accomplished by providing the %GOPSH command. The %GOPSH
command saves all such input-stream information, to be restored when
graphics mode is exited. If the processes can arrange to output blocks of
characters uninterruptibly, they can begin each block with a %GOPSH
followed by commands to initialize the input-stream state information as
they desire. Each block of graphics output should be ended by a %TDNOP,
leaving the terminal in its "normal" state for all the other processes, and
at the same time popping the what the %GOPSH pushed.
The input-stream state information consists of:
The cursor position
the state of XOR mode (default is OFF)
the selected set (default is 0)
the co-ordinate unit in use (physical dots, or virtual)
(default is physical)
whether output is going to the display screen or to a hardcopy
device (default is to the screen)
what portion of the screen is in use
(see "Using Only Part of the Screen")
(default is all)
Each unit of input-stream status has a default value for the sake of
programs that do not know that the information exists; the exception is the
cursor position, since all programs must know that it exists. A %TDINI or
%TDRST command should set all of the variables to their default values.
The state of the current set (whether it is visible, and where its
center is) is not part of the input-stream state information, since it
would be hard to say what it would mean if it were. Besides, the current
set number is part of the input-stream state information, so different
processes can use different sets. The allocation of sets to processes is
the server host's own business.
NWG/RFC# 746 RMS 08-MAY-78 20:45 43976
SUPDUP Graphics Extension
Using Only Part of the Screen:
It is sometimes desirable to use part of the screen for picture and
part for text. Then one may wish to clear the picture without clearing the
text. On display list terminals, %GOCLR should do this. On bit matrix
terminals, however, %GOCLR can't tell which bits were set by graphics and
which by text display. For their sake, the %GOLMT command is provided.
This command takes two cursor positions as arguments, specifying a
rectangle. It declares that graphics will be limited to that rectangle, so
%GOCLR should clear only that part of the screen. %GOLMT need not do
anything on a terminal which can remember graphics output as distinct from
text output and clear the former selectively, although it would be a
desirable feature to process it even on those terminals.
%GOLMT can be used to enable one of several processes which divide up
the screen among themselves to clear only the picture that it has drawn, on
a bit matrix terminal. By using both %GOLMT and distinct sets, it is
possible to deal successfully with almost any terminal, since bit matrix
terminals will implement %GOLMT and display list terminals almost always
implement sets.
The %TDCLR command should clear the whole screen, including graphics
output, ignoring %GOLMT.
Errors:
In general, errors in graphics commands should be ignored.
Since the output and input streams are not synchronized unless trouble
is taken, there is no simple way to report an error well enough for the
program that caused it to identify just which command was invalid. So it
is better not to try.
Errors which are not the fault of any individual command, such as
running out of memory for display lists, should also be ignored as much as
possible. This does NOT mean completely ignoring the commands that cannot
be followed; it means following them as much as possible: moving the
cursor, selecting sets, etc. as they specify, so that any subsequent
commands which can be executed are executed as intended.
NWG/RFC# 746 RMS 08-MAY-78 20:45 43976
SUPDUP Graphics Extension
Extensions:
This protocol does not attempt to specify commands for dealing with
every imaginable feature which a picture-drawing device can have.
Additional features should be left until they are needed and well
understood, so that they can be done right.
Storage of Graphics Commands in Files:
This can certainly be done. Since graphics commands are composed
exclusively of the ASCII characters 0 - 177, any file that can hold ASCII
text can hold the commands to draw a picture. This is less useful than you
might think, however. Any program for editing, in whatever loose sense, a
picture, will have its own internal data which determine the relationships
between the objects depicted, and control the interpretation of the
programs commands, and this data will all be lost in the SUPDUP graphics
commands for displaying the picture. Thus, each such program will need to
have its own format for storing pictures in files, suitable for that
program's internal data structure. Inclusion of actual graphics commands
in a file will be useful only when the sole purpose of the file is to be
displayed.
NWG/RFC# 746 RMS 08-MAY-78 20:45 43976
SUPDUP Graphics Extension
Note: the values of these commands are represented as 8.-bit octal
bytes. Arguments to the commands are in lower case inside angle brackets.
The Draw commands are:
Value Name Arguments
101 %GODLR <p>
Draw line relative, from the cursor to <p>.
102 %GODPR <p>
Draw point relative, at <p>.
103 %GODRR <p>
Draw rectangle relative, corners at <p> and at the
current cursor position.
104 %GODCH <string> <0>
Display the chars of <string> starting at the current
graphics cursor position.
121 %GODLA <p>
Draw line absolute, from the cursor to <p>.
The same effect as %GODLR, but the arg is an absolute
address.
122 %GODPA <p>
Draw point absolute, at <p>.
123 %GODRA <p>
Draw rectangle absolute, corners at <p> and at the
current cursor position.
The Erase commands are:
Value Name Arguments
141 %GOELR <p>
Erase line relative, from the cursor to <p>.
142 %GOEPR <p>
Erase point relative, at <p>.
143 %GOERR <p>
Erase rectangle relative, corners at <p> and at the
current cursor position.
144 %GOECH <string> <0>
Erase the chars of <string> starting at the current
graphics cursor position.
161 %GOELA <p>
Erase line absolute, from the cursor to <p>.
162 %GOEPA <p>
Erase point absolute, at <p>.
163 %GOERA <p>
Erase rectangle absolute, corners at <p> and at the
current cursor position.
NWG/RFC# 746 RMS 08-MAY-78 20:45 43976
SUPDUP Graphics Extension
The miscellaneous commands are:
Value Name Arguments
001 %GOMVR <p>
Move cursor to point <p>
021 %GOMVA <p>
Move cursor to point <p>, absolute address.
002 %GOXOR
Turn on XOR mode. Bit matrix terminals only.
022 %GOIOR
Turn off XOR mode.
003 %GOSET <n>
Select set. <n> is a 1-character set number, 0 - 177.
004 %GOMSR <p>
Move set origin to <p>. Display list terminals only.
024 %GOMSA <p>
Move set origin to <p>, absolute address.
006 %GOINV
Make current set invisible.
026 %GOVIS
Make current set visible.
007 %GOBNK
Make current set blink. Canceled by %GOINV or %GOVIS.
010 %GOCLR
Erase whole screen.
030 %GOCLS
Erase entire current set (display list terminals).
011 %GOPSH
Push all input-stream status information, to be
restored when graphics mode is exited.
012 %GOVIR
Start using virtual co-ordinates
032 %GOPHY
Resume giving co-ordinates in units of dots.
013 %GOHRD <n>
Divert output to output subdevice <n>.
<n>=0 reselects the main display screen.
014 %GOGIN <n>
Request graphics input (mouse, tablet, etc).
<n> is the reply code to include in the answer.
015 %GOLMT <p1> <p2>
Limits graphics to a subrectangle of the screen.
%GOCLR will clear only that area. This is for those
who would use the rest for text.
NWG/RFC# 746 RMS 08-MAY-78 20:45 43976
SUPDUP Graphics Extension
Bits in the SMARTS Variable Related to Graphics:
Note: the values of these bits are represented as octal 36.-bit words,
with the left and right 18.-bit halfword separated by two commas as in the
normal PDP-10 convention.
Name Value Description
%TQGRF 000001,,0 terminal understands graphics protocol.
%TQSET 000002,,0 terminal supports multiple sets.
%TQREC 000004,,0 terminal implements rectangle commands.
%TQXOR 000010,,0 terminal implements XOR mode.
%TQBNK 000020,,0 terminal implements blinking.
%TQVIR 000040,,0 terminal implements virtual co-ordinates.
%TQWID 001700,,0 character width, in dots.
%TQHGT 076000,,0 character height, in dots.
%TRGIN 0,,400000 terminal can provide graphics input.
%TRGHC 0,,200000 terminal has a hard-copy device to which output
can be diverted.
NWG/RFC# 734 MRC 07-APR-78 01:39 41953
SUPDUP Display Protocol
ACKNOWLEDGEMENTS
Richard M. Stallman (RMS@MIT-AI) and David A. Moon (Moon@MIT-MC) of
the MIT-AI and MIT-MC systems staff wrote the source documentation and the
wonderful ITS terminal support that made this protocol possible. It must
be emphasized that this is a functional protocol which has been in
operation for some years now. Stallman also wrote the section in this
document on the SUPDUP graphics extension.
In addition, Moon, Stallman, and Michael McMahon (MMcM@SRI-KL)
provided many helpful comments and corrections to this document.
For further reference, the sources for the some of the known SUPDUP
user programs are available online as:
Network Pathname Machine, Operating System
[MIT-AI]SYSENG;SUPDUP > PDP-10 ITS
[SU-AI]SUPDUP.MID[NET,MRC] PDP-10 SAIL
[SRI-KL]<MMcM>SD.FAI PDP-10 Tenex/TOPS-20
[MIT-AI]LMIO;LSOUP > MIT LISP machine
[SU-AI]SUPDUP.C[NET,MRC] PDP-11 Unix
The sources for the known SUPDUP server programs are:
[MIT-AI]SYSENG;TELSER > PDP-10 ITS
[SU-AI]SUPSER.MID[NET,MRC] PDP-10 SAIL